home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17293 < prev    next >
Encoding:
Text File  |  1996-08-05  |  6.1 KB  |  141 lines
  1. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  2. Path: in2.uu.net!allegra!alice!ark
  3. From: ark@research.att.com (Andrew Koenig)
  4. Subject: Re: Will Java kill C++?
  5. Message-ID: <DpvsE5.2HC@research.att.com>
  6. Organization: AT&T Research, Murray Hill NJ
  7. References: <4kn3c4$1ggc@piglet.cc.uic.edu> <Dpt0FD.Et4@research.att.com> <4ks0c8$jte@piglet.cc.uic.edu>
  8. Date: Mon, 15 Apr 1996 02:03:41 GMT
  9.  
  10. In article <4ks0c8$jte@piglet.cc.uic.edu> dhanle2@icarus.cc.uic.edu (David James Hanley) writes:
  11.  
  12. >     No, actually, when I was trimming the post, I accidentally 
  13. > clipped off your name, and made a typo when I typed it back in.  
  14. > I realize that mistyping your name is a mortal sin to the god of c++,
  15. > even if he projects his like for flaming strangers onto others.
  16.  
  17. If you had retracted your (claimed) inadvertent insult,
  18. I would have believed you.
  19.  
  20. > : Correct about what?  That having a name-mangling standard for C++
  21. > : would make C++ libraries easier to handle.  Sorry, but he's wrong,
  22. > : and so are you.
  23.  
  24. >     Nope. You're the one who is wrong here.  But seeing as you
  25. > replied to my first post about the matter with insults to me, I really
  26. > doubt you are interested in serious exploration of the matter.  But
  27. > hurling childish insults.
  28.  
  29. That's two mistakes.  The first one is believing that a name-mangling
  30. standard for C++ would solve any problems, the other is in believing
  31. that I am trying to insult you.
  32.  
  33. > : Name mangling, that is, the conventions that a compiler uses
  34. > : in translating names from the source program into names
  35. > : that the linker sees, is only one of a large number of things
  36. > : that must be agreed before programs compiled with one compiler
  37. > : can be linked with programs compiled with another.
  38.  
  39. >     Sure.  No one is saying anything different.  Name mangling
  40. > if only one of the obstacles to be overcome.  But many of these other
  41. > obstacles have been overcome on other platforms already.  It appears to
  42. > be somewhat stupid to make yet more obstacles by failing to standardize
  43. > something as simple as name mangling.
  44.  
  45. I completely agree that it seems stupid.  It is only on closer observation
  46. that the fundamental difficulty of doing so becomes apparent.
  47.  
  48. In order for a standard to have any meaning at all, that standard has
  49. to specify the behavior of something.  Moreover, any standard has to
  50. do so in a way that makes it possible to determine whether that 
  51. something meets the requirements of the standard or not.
  52.  
  53. Now, suppose a name-mangling standard existed.  What would it
  54. specify the behavior of?  Linkers?  What is a linker?  What if I
  55. give you a C++ implementation that has no linker at all?  Would you
  56. claim that such an implementation cannot be standard conforming
  57. because it does not have mangled names for you to inspect?  There
  58. is no such requirement on C implementations; why should there be
  59. such a requirement on C++ implementations?
  60.  
  61. Or what if I write a linker that does not use name mangling at
  62. all, but instead stores types in its symbol table?  Would you
  63. reject such a linker because it does not mangle names properly?
  64.  
  65. Of, for a third example, consider a compiler and linker that does
  66. follow the hypothetical name-mangling standard, but gives its users
  67. no way of determining what names it actually uses?  Does such a
  68. compiler/linker pair conform?  How can you tell?  How can you test
  69. conformance?
  70.  
  71. These are all questions that you must answer before you can even think
  72. about what a name-mangling standard might mean.
  73.  
  74. > :  If some
  75. > : of those things are made compatible and not others, that can
  76. > : easily make the problems worse instead of better.
  77.  
  78. >     How can it be worse than not working at all?  
  79.  
  80. Easy: it could work some times and not others.  That is the situation
  81. with some of my incompatible C compilers today: they work fine with
  82. lots of programs but crash with some.
  83.  
  84. > :  The reason
  85. > : is that programs may appear to work compatibly when in fact
  86. > : they are working only by accident.
  87.  
  88. >     Remind me to throw away all of my C programs in that case--they
  89. > a are all linked with a library compiled on a different compiler, 
  90. > and are therefore broken.  Pity.
  91.  
  92. OK, consider yourself reminded.
  93.  
  94. > : Well, good for you.  That still does not gainsay the fact that
  95. > : handing the same names to the linker does not make compilers
  96. > : compatible.
  97.  
  98. >     No, and again, no one said it did.  But a lot of work has been
  99. > done to allow link-compatibility within C libraries.  It seems foolish
  100. > to throw this all away.
  101.  
  102. Indeed.  But having a name-mangling standard would not affect this.
  103.  
  104. > : > : Getting a single binary library to work with both those
  105. > : > : C compilers is no easier than it is in C++.
  106.  
  107. > : >     Wrong.  As evidence, we do this all the time in C,
  108. > : > but I've never seen it done in C++. 
  109.  
  110. > : I completely agree with you that link compatibility between C++
  111. > : compilers is more difficult to achieve, hence less common, than
  112. > : link compatibility between C compilers.
  113.  
  114. >     Whups!  A few lines above you said it was no easier!
  115.  
  116. Did I?  Where?
  117.  
  118. > : But agreeing on a standard for name mangling would not solve that
  119. > : problem, because it is vanishingly rare that two C++ compilers are
  120. > : binary compatible in all details except for names.
  121.  
  122. >     Right.  Since the name mangling is unspecified, why stick to the
  123. > standard techniques for the platform?  We can squeeze out another 5% of
  124. > performance by passing the first paramater as a register( or whatever ).
  125. > Binary incompatibility between compilers is a serious problem, for sharing
  126. > of libraries, and other such activities, and it sure would help things
  127. > if the committee could have put it in the standard, removing yet one
  128. > more problem.  I mean, they added literal "and" and "or" for bob's sake.
  129.  
  130. Putting name mangling into the standard -- if anyone could figure out
  131. how to do it meaningfully -- would not remove any problems.  If two compiler
  132. vendors want to be compatible with each other, they will do so, with or
  133. without a name-mangling standard.  If they want to be incompatible with
  134. each other, they will also do so.
  135.  
  136. By the way, why aren't you agitating for a name-mangling standard in C?
  137. Name mangling is a potential problem there too.
  138. -- 
  139.                 --Andrew Koenig
  140.                   ark@research.att.com
  141.